Computer networks are vulnerable to many threats that can inflict damage that can result in significant losses. These losses can stem from a number of sources including environmental hazards, hardware and software failure, user errors, or even malicious acts of others. A goal of network security is therefore to protect the confidentiality, integrity, and availability of information stored electronically in a network from these threatening sources.
In general, a network is a distributed computing environment with two or more hosts connected to a common framework for information exchange. Communication among networks and hosts within networks is frequently based on the OSI Model and is in accordance with a protocol, such as a TCP/IP protocol. Both the OSI Model and TCP/IP will be understood by one of ordinary skill in the art.
With the TCP/IP protocol, data to be communicated is placed in data packets. FIG. 1 illustrates the structure of a standard IP packet, which will be familiar to one of ordinary skill in the art. The packet 111 includes a header 115 and a data portion 110. The fields of the IP header are generally well-known in the art, and are described in detail in RFC-791, “Internet Protocol,” Postel, September 1981 (available at www.ietf.org/rfc). Nonetheless, the fields are summarized here.
The Version field 130 describes the version of the Internet protocol being used by the machine sending the data. Since header length is not constant, the Internet Header Length (IHL) 135 describes the number of the 32-bit words in the header 115. The IHL field 135 allows the receiving machine to calculate where the header 115 ends and the data 110 portion begins.
The Type of Service field 140 provides an indication of the abstract parameters of the quality of service desired. For instance, various combinations of reliability and speed are available.
The Total Length field 145 is the length of the packet, measured in octets 125, including the header 115 and data 110. An Identification field 150 is assigned by the sender to aid in assembling fragments of a packet.
A three bit field of various control flags 155 is provided. The first bit is unused and always zero. The next bit DF is a “Don't fragment” bit: it allows fragmentation when set to 0 but indicates no fragmentation when set to 1. If DF is set to “1,” it is an order to routers not to fragment the packet because the destination is incapable of putting the pieces back together again. The third bit MF is a “More Fragments” bit: it indicates the last fragment in series when set to 0; it indicates that there are more fragments in the series when set to 1.
The Fragment Offset field 160 indicates where in the entire datagram the fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero.
The Time to Live (TTL) field 165 indicates the maximum time the datagram 111 is allowed to remain in the internet system. The Protocol field 170 indicates the next level protocol used in the data 110 portion of the packet. The Header Checksum 175 verifies the header only and is recomputed and verified at each point that the header 115 is processed.
The Source address 180 and Destination address 185 are 32 bit fields used to indicate the source and destination of a packet. The Options field 190 varies and may or may not appear in the packet 111. The Options field may also be padded to ensure that the header 115 ends on a 32 bit boundary.
Several conventional resources are available to protect a network from information losses. For instance, firewalls are used to enforce a boundary between two or more networks to filter incoming traffic (generally from the Internet) according to a security policy. Still, firewalls are inadequate to fully protect a network since users may not always obtain access to a network through the Internet (for instance, a user could circumnavigate the firewall by using a modem connection). In addition to the many ways a network can be attacked externally, not all threats originate outside the firewall and can come from within the network. Further, firewalls themselves are subject to attack many of which can render the firewall ineffective.
Therefore, networks need to rely on resources other than firewalls for network security. Such resources include vulnerability assessment tools.
Vulnerability assessment tools perform examinations of a network to determine weaknesses in the network that might allow security violations. The results of a vulnerability assessment tool represent a snapshot of a network's security at a particular point in time. Thus, vulnerability assessment tools determine where in a network an attack is possible.
Vulnerability assessment tools typically use two methodologies, either separately or in conjunction, for performing the network examination: (1) an active inspection of a network that launches known malicious attacks against the network to determine the network's susceptibility to those attacks; and/or (2) a passive inspection of a network that inspects the network's device and service configurations (known as service banners) for particular settings that are known to be vulnerable to attacks.
The active methodology actually reenacts a series of known attacks, recording the results of the attacks to discover vulnerabilities in the network. “Known attacks” are generally the methods and exploit scripts that can be commonly referenced on security related Internet locations or sites (e.g., www.rootshell.com) and mailing lists (e.g., BUGTRAQ) that are also often referred to by hackers (also referred to as crackers) to construct attacks on a network or individual machine. Using this active methodology, a vulnerability is discovered when the reenacted attack is able to penetrate the network and, in many instances, “crash” or disable the network. Obviously, a severe limitation of this methodology is that an undue risk is put on the network being tested. For instance, should a vulnerability be detected by the test attack resulting in a network crash, information on the network may be lost.
The passive methodology does not subject the network to the undue risk of the active methodology, but it has other limitations. The passive methodology checks packet information, commonly known as “service banners,” that identifies network services and devices. The service banner is used to check a database of known vulnerabilities for that particular service banner.
A service banner generally contains four fields. For example, consider the following sample service banner:
220-FTP Server (wuftpd 2.4.2) ready.
In this example, Field 1 is the number 220, and is a reply code indicating the service is ready for a new user. Field 2, here “FTP Server,” identifies the type of service being used. Field 3, here “(wuftpd 2.4.2),” indicates the software and version of the service. And Field 4, “ready,” is a message indicating that the service is ready for user supplied input.
The service banner is easily obtained from a network by using telnet to access ports on which services processes are resident. The telnet protocol will be understood by those in the art, and is described in the RCF-764, “Telnet Protocol Specification”, J. Postel, Jun. 1, 1980 (available at www.ietf.org/rfc). In this methodology, the service banner is then compared against a database of service banners that have a list of known vulnerabilities.
While the passive methodology may be safer than the active methodology, it is not accurate or reliable for many reasons. First, service banners are easily configurable and may not accurately name the type of network service enabled on a host. Thus, in the service banner example above, the service is defined in fields 2 and 3 of the banner as FTP Server (wuftpd 2.4.2). That service may be reconfigured easily by an individual so that the network service is no longer accurately described by the service banner. Therefore, any vulnerability detected for the inaccurate device or service would be a false detection. In particular, hackers will commonly attempt to hide any “back doors” or vulnerabilities found in a network by editing the service banner information so that another hacker will not be able to notice a quick entrance into the network. Some vulnerabilities are therefore hidden from this passive methodology.
Another reason using service banners is unreliable is that service banners do not accurately reflect the patch level of the network service and therefore critical fixes to the network may have been applied that are not reflected in the service banner. Patch levels refer to the degree to which the source code of the service or program has been modified by functionality or security fixes. A patch is understood as a specific alteration in the code of a service or program for the purpose of altering some specific aspect of the service or program's functionality or eliminating a bug or security risk.
Still another reason that use of service banners as a means of vulnerability detection is undesirable is that it places systems on the network in undue risk. In particular, service banners must be openly displayed in order for the presence of vulnerabilities in a network to be inferred. As such, the service banners are available to any remote user, malicious or otherwise. A common method of network reconnaissance employed by hackers is to examine the service banners on machines across a network in order to identify vulnerable points of attack.
One alternative to these two methodologies (active and passive) has been to use a method of information gathering known as “fingerprinting.” This method is described in the publication entitled “Remote OS Dectection Via TCP/IP Stack Fingerprinting” by Fyodor, dated Oct. 18, 1998. This publication describes a “fingerprinting” of the operating system of machines on a network for purposes of determining the operating system type. Once an operating system is known, then other techniques may be employed to assess a vulnerability (fingerprinting does not itself assess vulnerabilities).
Nonetheless, while fingerprinting can identify the operating system in some instances, it cannot always do so accurately, and it cannot identify the patch level of the operating system. Moreover, while fingerprinting can sometimes identify active ports in use by a host, it cannot always do so accurately and it cannot identify the services that are running on those ports. All of these deficiencies limit the accurate detection of vulnerabilities.
A need therefore exists for a method and system of detecting vulnerabilities that does not subject the network being analyzed to undue risks (unlike the active approach), is accurate and reliable (unlike the passive approach), and is able to accurately identify more information from the network than only the operating system (unlike the Fyodor approach). A further need exists for a method and system that not only detects current vulnerabilities of a network, but also infers vulnerabilities not yet existing on the network.